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We present a type checking algorithm for establishing a session-based discipline in the pi calculus 
of Milner, Parrow and Walker. Our session types are qualified as linear or unrestricted. Linearly 
typed communication channels are guaranteed to occur in exactly one thread, possibly multiple times; 
afterwards they evolve as unrestricted channels. Session protocols are described by a type constructor 
that denotes the two ends of one and the same communication channel. We ensure the soundness 
of the algorithm by showing that processes consuming all linear resources are accepted by a typing 
system preserving typings during the computation and that type checking is consistent w.r.t. structural 
congruence. 



1 Introduction 

Session types allow a concise description of protocols by detailing the sequence of messages involved 
in each particular run of the protocol. Introduced for a dialect of the pi calculus (HEEL the concept has 
been transferred to different realms, including functional and object-oriented programming and operating 
systems; refer to [2] for a recent overview. 

To illustrate, consider the problem of designing a web system for the scheduling of meetings. In 
our example, the system is implemented by means of a web service repeatedly waiting for requests to 
create a poll. Once invoked, the service instantiates a fresh session for the poll and launches a thread 
for managing it. In the pi calculus [9] the session could be modeled as a communication channel for 
the exchange of the messages required by the scheduling protocol. The fresh channel for the poll is 
forwarded back to the invoker on the channel she has provided in order to receive the information needed 
for the start of the poll: the title and a tentative date for the meeting. Afterwards the thread repeatedly 
waits for possible date proposals from the participants of the poll. 

A =\x(y).(vp)(y(p).p(t\t\e).p{date).\p(date)) 

In order to have some guarantee on the behavior of the executable system, a static analysis of its code 
should be performed during the compilation. A typed analysis permits indeed to verify the desired 
properties of the protocol, namely that there is exactly one title and at least one date proposal for the 
meeting. To this aim we need to enforce that the capability forwarded to the caller consists in (i) send 
a string for the title and afterwards (ii) send one or more dates. This behavior could be described by 
relying on polymorphic types qualified as linear or unrestricted. The idea is to introduce qualifiers for 
types describing a session and to allow a linear usage of a session to evolve to an unrestricted usage. This 
approach has been indeed advocated as effective independently from any programming language lH4l . 
A qualified session type for the poll channel sent to the invoker is the one below. 

S2 = li n Istring.lin !date.54 S4 = un Idate.S^ 

The session type first describes the sending of a string to set the title of the meeting; such usage is 
qualified as linear because a title for the schedule is required. Similarly, the continuation type for sending 
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the date of the schedule is qualified as linear because a date has to be set in order to start the poll. Lastly 
zero or more date proposals could be send on the poll channel; this behavior is described by a unrestricted 
recursive type. The continuation of the service P\ is described by the type Si below that could be seen as 
the "dual" ofS 2 . 

Si = lin ?string.lin ?date.5 , 3 S3 = un ?date.S3. 

The session type describes the behavior of receiving the title and one or more date proposals for the 
schedule. The receiving of the title and of the date proposal are both qualified as linear because this 
information is mandatory. Eventually, zero or more date proposals will arrive afterwards. The unbounded 
behavior of receiving such proposals is described by the unrestricted recursive type S3. The usage of the 
poll channel is described by a type constructor (Si,S2) representing the concurrent behavior of the two 
channel ends flU. The intuition is that in typing (the continuation of) service Pi the type (Si, £3) is split 
into two parts: the linear output end point is used to type the delegation of one end of the session to the 
invoker while the linear input end point is used to type the continuation process. 

While the idea of split types and contexts is clear and concise, the inherent non-determinism con- 
tained in its formulation makes a direct implementation infeasible. Algorithmic solutions for linear func- 
tional languages avoid to split the context into parts before checking a complex expression by passing the 
entire context as input to the first subexpression and have it return the unused portion as an output |[T5ll . 
In the setting of concurrent computations, the idea is that when typing a parallel process P \ Q the set 
of linear identifiers used by P must be calculated in order to remove it before type checking Q. This 
approach, previously outlined for linear types of pi calculus in Q, has been implemented in the session 
system of [3] by representing each channel end with a distinct identifier. 

In this paper, we propose an algorithm to check protocols described by types of the form (S\,S2) 
where each S, is a qualified session type depicting one end of the communication. Channels could evolve 
from linear to unrestricted usage. Reasoning at the type level, we do implement split by forbidding the 
utilization of used parts of types and by a careful analysis of qualifiers. This construction permits us to 
show that (i) type checked processes are accepted by a typing system satisfying subject reduction and 
that (ii) type checking preserves structural congruence. 

More in detail, type checking relies on the definition of several unambiguous patterns. The patterns 
for linear input and output processes do return a marked context. In the body of the function a recursive 
call to type check the continuation is launched. If an exception is not raised, this call returns in output 
a context. First, to ensure a subsequent linear usage to be finished within the continuation we verify 
the type for the variable in the context to be unrestricted. Second, to prohibit the use of the variable in 
the next thread we return a context with an "unusable" mark for the type of the variable. Similarly, in 
delegating a channel end of a session we pass to the checking function for the continuation a context with 
an unusable mark for the delegated type. Under replication, we do no admit to return new typings marked 
as unusable, which would imply consumption of a linear resource. Lastly, the algorithm succeeds if the 
context returned by the top-level call of the type checking function does not contain linear types. 

The remainder of the paper is as follows. In Section [2] we introduce session types and pi calculus. 
Section [3] presents the type checking algorithm. Section [4] is devoted to establish the soundness of our 
approach. In the last part of the section we investigate the expressiveness of the algorithm. Some exam- 
ples of the concrete execution of the algorithm are illustrated in Section [5] We conclude in Section [6]by 
discussing limitations and future work. 
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Types and Processes 





Qualifiers: 


T ::= 


Types: 


lin 


linear 


5 


end point 


un 


unrestricted 


(S,S) 


channel 




Pre Types: 


P ::= 


Processes: 


1T.S 


receive 


x(y).P 


output 


\T.S 


send 


x(y).P 


input 


end 


termination 


P\P 


composition 




End Point Types: 


(vx : T)P 


restriction 


qp 


qualified channel 


IP 


replication 


a 


type variable 





inaction 


pa.S 


recursive type 







Rules for structural congruence 

P\Q = Q\P (P\Q)\R = P\(Q\R) P\0 = P \P = P\\P 
(vx :T)P\Q= {vx :T)(P\ Q) {vx : Ti)(vy : T 2 )P = {vy : T 2 )(vx : Ti)P 
(v* : un/?)0 = (vx : (un/?i, un/? 2 ))0 = 

Rules for reduction 

x(z).P | x(y).Q -> P | Q[z/y] [R-Com] 
P -> Q P -»• Q P = P' P' -> Q' Q' = Q 

(vx)P -> {vx)Q P\R-> Q\R P -r Q 

[R-Res] [R-Par] [R-Struct] 



Figure 1: Pi calculus 



2 Pi calculus 



This section introduces the syntax and the semantics of the typed pi calculus. The definition is in 
Figure [T] We consider channel types of the form (5,5) where 5 is a type describing the behavior of 
a channel end point. An end point type 5 can be a pre type qualified with lin or un, a recursive type or a 
type variable. Each qualifier in a type controls the number of times the channel can be used at that point: 
exactly once for lin; zero or more times for un. A pre type of the form !7\5 describes a channel end able 
to send a variable of type T and to proceed as prescribed by 5. Similarly, pre type 7T.S describes a chan- 
nel end able to receive a variable of type T and continue as 5. Pre type end describes a channel end on 
which no further interaction is possible. For recursive (end point) types we rely on a set of type variables, 
ranged over by a. Recursive types are required to be contractive, that is, containing no subexpression of 
the form pai . . .pa n .a\. Type equality is not syntactic. Instead, we define it as the equality of regular 
infinite trees obtained by the infinite unfolding of recursive types, modulo pair commutation. The formal 
definition, which we omit, is co-inductive. In this way we use types (/la.lin!unend.lin?unend.a, unend) 
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and (unend,lin!unend.jU^lin?unend.lin!unend.&) interchangeably, in any mathematical context. This al- 
lows us never to consider a type pLa.S explicitly (or a for that matter). Instead, we pick another type in 
the same equivalence class, namely S\fla.S/a]. If the result of the process turns out to start with a ju, we 
repeat the procedure. Unfolding is bound to terminate due to contractiveness. In other words, we take an 
equi -recursive view of types ifTOl . 

The syntax and the semantics of pi calculus processes are those of [9 ] but for restriction, for which 
we require type annotation. This is only to facilitate type checking and has no impact on the semantics. 
We rely on a set of variables, ranged over by x,y,z. For processes we have (synchronous, unary) output 
and input, in the forms x(y).P and x(y).P, as well as a parallel composition, annotated scope restriction, 
replication and the terminated process. The binders for the language appear in parenthesis: x is bound 
in both y(x).P and (vx : T)P. Free and bound variables in processes are defined accordingly, and so is 
alpha conversion, substitution of a variable x by a variable z in a process P, denoted P[z/x\. We follow 
Barendregt's variable convention, requiring bound variables to be distinct from each other and from free 
variables in any mathematical context. 

Structural congruence is the smallest relation on processes including the rules in Figure [T] The first 
three rules say that parallel composition is commutative, associative and has as neutral element. The last 
rule on the first line captures the essence of replication as an unbounded number of identical processes. 
The rules in the second and third line deal with scope restriction. The first, scope extrusion, allows the 
scope of x to encompass Q; due to variable convention, x bound in (vx : T)P, cannot be free in Q. The 
next rule allows exchanging the order of restrictions. The rules on the third line state that restricting 
over a terminated process has no effect. Since it makes poor sense to declare a new variable with a 
linear type for a terminated process, we require the type annotation to be unrestricted. The reduction is 
the smallest relation on processes including the rules in Figure [T] The [R-Com] rule communicates a 
variable z from an output prefixed one x(z) P to an input prefixed process x(y).Q; the result is the parallel 
composition of the continuation processes, where the bound variable y is replaced by the variable z in 
the input process. The rules on the last line allow reduction to happen underneath scope restriction and 
parallel composition, and incorporate structural congruence into reduction. 



3 Type checking algorithm 

In this section we present an algorithm for type checking a pi calculus process given a typing context. 
Type checking relies on the definition of several patterns which, for the sake of clarity, we present in a 
declarative style. Lastly, in Figure [2] we present an excerpt of the ML implementation. 

Contexts. We let T be a map from variables to types and the void symbol, noted o; a void symbol permits 
to mark an end point as unusable. 

M,N,0 ::= S\o entry 
r ::= | T,x:M | T,x: (M,N) context 

Context updating, noted l±), is the procedure effected by the typing system to transform a void entry in an 
end point entry: r,x : o l±)x : M = T,x : M. A safe context is a map from variable to safe entries; we let 
the predicate safe(r) hold whenever x G dom(r) implies safe(r(x)). A linear channel type is safe if (i) 
the type of the variable sent in output corresponds to the type expected in input and (ii) the expected type 
for the input is safe and (iii) the continuation is safe. For an unrestricted channel type we require (i) and 
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(ii): (iii) will be enforced by the type system. 

safe(M) 

safe((Mi,M 2 )) 3/ G {1,2}. M; = o,unend 

safe((lin lin !7\S 2 )) = safe(T) Asafe((5i,5 2 )) 
safe((un?r.5i,un!r.5 2 )) = safe(r) 

A context is unrestricted if it contains only unrestricted or void entries. We let un(T) whenever x € 
dom(r) implies un(T(x)). 

un(o) 
un(un p) 

un({M,N)) = un(M) A un(JV) 

Patterns. We present typing rules for processes of the form Ti h Pt>r 2 where i"i is a context received in 
input and T 2 is a context produced as output. Given that F\ is a context such that safe(Ti), the rules are 
chosen deterministically by inspecting (i) the shape of the context and (ii) the shape of the process, in the 
following way. Each rule is implemented as a pattern of a function with signature check(g : context, p : 
process) : context. For each function call with a safe context parameter, zero or one pattern does match; 
in the first case a pattern exception indicating the reject of the process is raised while in the second case 
a context is returned in output to the caller. The rules for variables have the form F\ h v : T > T 2 and are 
implemented as patterns of a function with signature checkVar (gxontext, v:var):context . In the rules 
below the output context is obtained by setting to void the linear assumptions used to type the variable. 
The last three rules permit to resolve any ambiguity in typing an unrestricted end point type with an 
unrestricted channel type. 



r = Ti,x: linp,r 2 r = ri,x: un/?,r 2 



Thx: \\np\>Fi,x: o,r 2 Thx: unp>F 

r = Ti,x: (linpi,lin/? 2 ),r 2 



Tl-x: (lin/?i,lin/? 2 )>ri,*: (0,0), F 2 

r = Ti,x: (linpi,linp 2 ),r 2 
Tl-x: (linp 2 ,linpi)>ri,x: (0,0), T 2 

r = r b x: (lin/?,A0,r 2 r = r u x: (M,lin^),r 2 



rhx: \\np>Fi,x: (o,N),T 2 T\~x: \\np>Ti,x: (M,o),T 2 

r = r u x: (unpi,un/7 2 ),r 2 r = Ti,x: (un^i,unp 2 ),T 2 
Thx: (un/?i, unp 2 ) >F Fhx: (un^ 2 , un/?i) >T 

r = Ti,x: (unp,N),F2 unp^N T = T\,x: (M,un/?),r 2 unp^M 
Thx: un^l>r Thx: un/?[>r 

r = Ti,x: (unend, unend),r 2 
r h x: unend I>r 



[A-V-L],[A-V-U] 

[A-V-LL-L] 
[A-V-LL-R] 

[A-V-L-R],[A-V-L-L] 

[A-V-UU-L],[A-V-UU-R] 

[A-V-U-L],[A-V-U-R] 

[A-V-EE] 



Rule [A-OUT-L] is to type processes sending variables on a channel used in linear mode given that the 
type for the channel in the context is an end point. The context changed by setting the channel to void is 
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used to check the sent variable at the expected type and in turn to return a new context. The new context 
updated with the continuation type for the linear channel is passed as parameter in the call for checking 
the continuation process. To ensure a linear use of the channel to be finished within the continuation, we 
verify that the context returned by the call for the continuation does contain an unrestricted typing for 
the channel. Finally, the returned context is given as output with the typing for the channel set to void. 



r u x:ohy:T>r 2 F 2 \Sx: S h Pt>F 3 ,x : M un(M) TA Out LI 

F u x: \\n\T.Shx{y).P>F 3 ,x:o L - UT- J 

Rules [A-Out-L-l],[A-Out-L-r] are used when the entry for the linear output in the context is a 
channel type. The rules are implemented by the pattern [A-Out-L]. In returning the context we set one 
end of the channel type to void while we leave the other end as it has been received in input. 



F u x: \\n\T.Shx(y).P>r 3 ,x:o 
Ti,x: (\\n\T.S,N)hx(y).P>T 3 ,x: (°>#) 

F u x: \\n!T.S\-x(y).P>r 3 ,x: o 
T u x: (M,\\n\T.S)hx(y).P>r 3 ,x: (M,o) 

For sending a variable on an unrestricted channel we require the sent variable to be typable by the 
same context received in input; that is, the type for the unrestricted output channel must be recursive. 
The context obtained by the typing for the variable is then used to call the checking function for the 
continuation process. 



[A-OUT-L-L] 
[A-OUT-L-R] 



r u x:S\-v: T>F 2 T 2 hP>T 3 S = un\T.S 

~ r„ J :unir.5H(v).p t .r 3 [A " 0UT - UNI 

rM=(s.AQi-,= r»n r^por, s = m vs [a . 0ut -un-l] 

F u x: (un\T.S,N)hx{y).P>r 3 
r h x: (M,S) hv: T>T 2 T 2 hPt>r 3 S = un\T.S 

r^W^WWM^ri [a-out-un-r] 

To type a linear usage of an input we require the expected type to agree with the type of the input 
channel and the continuation type for the channel to be consumed within the continuation. This is 
implemented by requiring that the context returned by the call for the continuation does map the variable 
to an unrestricted type. We also require a linear usage for the variable bound by the input to be finished 
within its local scope. Lastly, the call returns a context (i) with the type for the linear variable set to void 
and (ii) pruned by the variable bound by the input prefix. This is the rationale of rule [A-lN-L] and or 
rules [A-In-L-l],[A-In-L-r] which are used for variables having respectively an end point or a channel 
type. 
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ri,x: S,y: T\-P>T 2 ,x:M,y : O un(M) un(<9) 
Ti,x: \\nlT.S\- x(y).P>T 2 ,x : o 

Ti,x: \\r\1T.S h x(y).P>T2,x : o 
r u x: (\\nlT.S,N)hx(y).Pi>r 2 ,x: (o,N) 

F h x: WnlT.S\-x{y).P\>T 2 ,x:o 
r u x: (M,\\n?T.S)hx(y).P>r 2 ,x: (Af,o) 



[A-IN-L] 
[A-lN-L-L] 
[A-lN-L-R] 



The rules for unrestricted input take the context received in input and add the bound variable at the 
expected type in order to type the continuation. The context returned by the call of the checking function 
for the continuation needs to be first verified to ensure that the type for the bound variable is unrestricted, 
and then pruned by the variable to be returned in output. 



r b jc: S,y: T\-P>T 2 ,y.O un(O) S = un?T.S 
F u x: unlT.Shx(y).P>r 2 

ri,x: (S,N),y: T h P>T 2 ,y : O un(O) 5 = un?r.5 
T u x: (un?T.S,N)hx(y).P>r 2 

ri,x: (M,S),y: T\-P>T 2 ,y: O un(0) S = unU.S 
n.jc: (M,un?r.5) \~x(y).P>r 2 



[A-In-Un] 
[A-In-Un-l] 
[A-In-Un-r] 



To type an inert process by using [A-lNACT] any context suffices; the context received in input is for- 
warded in output. To type a parallel process in [A-Par] we check the first thread with the context 
received in input. This operation returns in output a context that is used to type-check the next thread. 
The context returned by the last typing is forwarded in output. While imposing an order on parallel 
processes could appear restrictive, in Section|4]we will show that the chosen order makes no difference. 

rho^r — 2 — — — 3 [a-inact],[a-par] 

rih/ 5 |<2>r 3 

In order to type a process generating a new channel, in rule [A-Res] we require the typing for the channel 
to be safe; if it is not, the algorithm stops and an exception is raised. Similarly to the input cases, if a 
linear usage is prescript for the new variable then it must be finished within its scope. 

safe(r) ri,y:rhf>r 2 ,y:Q un(O) 
ri h (vy: T)P>F 2 

The rule for replication [A- Repl] is below. In the call for checking the process under the replication 
we require the context returned in output to be equal to the one received in input. Indeed, a change in 
the output context would be obtained by introducing a void symbol indicating that a linear resource has 
been consumed. This must clearly be forbidden under replication. On contrast, we allow to return linear 
entries in order to type check the next thread. 



rihPt>r 2 r 2 = rj 
n hp>f 2 



[A- Repl] 
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datatype qualifier 


= Lin I Un; 








datatype preType 


= In of sessionType * endpointType I Out of sessionType * endpointType I End 


and endpointType 


= Qualified of qualifier * preType I Void 








and sessionType 


= EndPoint of endpointType I Channel of endpointType * endpointType; 




type context 


= (string * sessionType) list; 








datatype process 


= Zero I Replication of process I Parallel of 


process * process 






1 Input of string * string * process I Output of string * string * process 




1 New of string * sessionType * process; 








fun safe 


(g: context) : context ; 








fun unVar 


(g: context, v: string) : context; 








fun remove 


(g : context , v : string) : context ; 








fun setVoid 


(g : context , v : string) : context ; 








fun checkVar 


((x, ((EndPoint (Qualified (Lin.p) ))))::g, 










(z, ((EndPoint (Qualified (Lin.r) ))))) = 










if p=r then (x, (EndPoint Void))::g 




(* A-V-L 


*) 


1 checkVar 


((x, ((EndPoint (Qualified (Un,p) ))))::g, 










(z, ((EndPoint (Qualified (Un.r) ))))) = 










if p=r then ((x, ((EndPoint ( Qualified (Un,p) ))))::g) 


(* A-V-U 


*) 


1 checkVar 


((x, ((Channel (Qualified (Lin.p) , Qualified 


(Lin.s) )))) : :g, 








(z, ((Channel (Qualified (Lin.r) , Qualified 


(Lin.t) )))))= 








if p=r andalso s=t then 










((x, ((Channel ( Void, Void ))))::g) 










else 










if p=t andalso s=r 










then ((x, ((Channel ( Void, Void )))): 


:g) (* 


A-V-LL-L+R *) 


1 checkVar 


((x, ((Channel (Qualified (Lin.p) , Void )))): 


:g. 








(z, ((EndPoint (Qualified (Lin.r)))))) = 










if p=r 










then ((x, ((Channel ( Void .Void )))):: 


g) 


(* A-V-L-R *) 


1 checkVar 


((x, ((Channel (Qualified (Lin,p) , Qualified 


(Un,s) ))))::g, 








(z, ((EndPoint (Qualified (Lin.r)))))) = 










if p=r 










then ((x, ((Channel ( Void, Qualified 


(Un,s)))))::g) 


(*A-V-L-R 


*) 


(* 


A-V-L-L I A-V-UU-L I A-V-U-L I A-V-U-R 


1 A-V-E-E 




*); 


fun check 


(g : context , Zero : process) = 










g 




(* A-INACT 


*) 


1 check 


(g: context .Replication p)= 










if g = check(g.p) 










then g 




(* A-REPL 


*) 


1 check 


(g:context, Parallel (pl,p2)) = 










check ( check (g,pl) , p2 ) 




(* A-PAR 


*) 


1 check 


( (z, (Endpoint (Qualified (Lin, In (a,c)) )))::t 


, Input (x,y,p))= 








let val d = check ((x, Endpoint (c))::t,p) in 








setVoid ( remove (unVar (unVar (d,x), y) , y) , x ) 








end 




(* A-IN-L 


*) 


1 check 


(g: context , New (x,t,p) ) 










remove ( unVar ( check ( ( safe( [(x,t)] ))@g 


, p) , x ) , x) 


(* A-RES 


*) 


(* 


A-IN-L-1 I A-IN-L-r I A-IN-Un I A-IN-Un-1 


1 A-IN-Un-r I A- 


OUT-L 






A-0UT-L-1 I A-OUT-L-r I A-OUT-Un I A-0UT-Un-1 


1 A-OUT-Un-r 




*); 


fun typeCheck 


(g: context ,p :process) = 










un ( check ( safe(g) , p ) ); 









Figure 2: ML code of the algorithm (excerpt) 



104 



A type checking algorithm for qualified session types 



Lemma 3.1. If safe(T\) andT\ h P>T2 then dom^) = dom(ri) and safe^). 

Type checking. Having defined typing rules corresponding to patterns of the checking function, we 
devise an algorithm for establish a session-based type discipline. Figure [2]presents the ML definition for 
types, processes and the type checking function. Type context associates variables to entries which are 
formed apart the end point and the channel type. The function safe returns in output the same context 
received in input whenever the context satisfies the safe predicate, otherwise it generates an exception. 
Function unVar takes as parameters a context and a variable and verifies that the type for the variable in 
the context is unrestricted; in this case the context is returned in output, otherwise an exception is raised. 
Functions remove and setVoid do perform the required operations and return the updated context. We 
also need auxiliary functions to push and pop entries to and from the context stack; we omit all the 
details. 

The check function, the kernel of the type checking procedure, is defined by the union of the patterns 
for the rules introduced in the current section. In order to illustrate the mechanism, we draw the trans- 
lation of some patterns. In patterns for variables and in [A-lN-L] we assume the variable on the top of 
the context z to be equal to the variable x respectively for the value to type and for the input prefix of the 
process. The checkVar function is called in patterns for output in order to type the sent variable and ob- 
tain in output a context to pass together with the the continuation to the checking function. In [A-lN-L] 
we launch the recursive call of the check function by passing as parameters the updated context and the 
continuation process. After checking that the type for both channel x and the variable bound by the input 
are unrestricted in the returned context, we return the context with the type for x set to void. In the pattern 
for [A-Res] we launch the check function by passing as parameters the context with the new entry and 
the continuation process. The inner call of the safe function immediately raises an exception if the type 
for the bound variable is not safe. Lastly, we first control that in the returned context the variable is 
unrestricted and then we return the context pruned by the variable. The algorithm is implemented by the 
typeCheck function. The function receives in input a context and a process. If the context received in 
input is not safe then the function exits immediately. Otherwise, a context is returned in input provided 
that an exception has not been raised. The exception could raise (i) when no pattern matching is possible 
for the chosen derivation or (ii) when a call of the safe function in [A-Res] fails or (iii) when call of 
unVar function fails. Since the choice of patterns is deterministic for safe contexts, no backtracking is 
needed. Lastly, the process is accepted by the algorithm whenever the returned context satisfies the un 
predicate defined in Section|2] 

Lemma 3.2. If safe(r) then check(r,P) matches zero or one patterns. 

Lemma 3.3. /fcheck(r / ,P / ) has been recursively invoked by typeCheck(r,f ) then we have safe(r'). 

Proof. A call is a match of a pattern Ti h P&Y2 which is an axiom whenever P = 0, and has been inferred 
from an hypothesis starting with a type environment A on the left otherwise. We proceed by induction and 



show a stronger result, namely that safe(A) implies safe(Ti ). We close the proof by applying Lemma 3.1 



and eventually by exploiting transitivity in cases for output and parallel composition. □ 

Corollary 3.4. 7/'check(r / ,P / ) is a call invoked during the execution o/typeCheck(r,/ 5 ) then there are 
zero or one patterns to match. 



4 Soundness 



This section is devoted to establishing the soundness of the algorithm. To this aim we project the pattern 
rules presented in Section [3] into the typing system of Figure [3] which satisfies subject reduction Q. 
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Context splitting rules 

I = h-h T = unp or (unpi,unp 2 ) 
I,x:T = (I u x:T)-(I 2 ,x:T) 
I = h~h r = linp or (linpi, lin/72) I = h'h T = \\r\p or (linpi, \\np 2 ) 
I,x:T = (h,x: T)-I 2 7,x: T = I r (h,x: T) 

/ = /i-/ 2 

7,x: (lin^i,lin/j 2 ) = linpi) • (/2,x: lin/? 2 ) 

7 = / 1 / 2 



I,x: (linpi,unp 2 ) = (I u x: (\\npi,unp 2 )) ■ (I 2 ,x: unp 2 ) 
I = h-I 2 



I,x: (linpi,unp 2 ) = (h,x: unp 2 ) ■ (I 2 ,x: (linpi, unp 2 )) 

Typing rules for values 

un(I) /hov: (5, un p) 



I,x:T\~dx:T Ihpv.S 
Typing rules for processes 

un(7) /j>p^i / 2 Kz)7? 2 

/h D hh\-DRl \R 2 

Ih D R un(7) Ix:T\- D R safe(T) 

7h D !/? /ho (vjc: r)7? 

I,x: S,y: Th D R (*) /ih D v:r I 2 ,x:Sh D R (**) 



[T-Var] [T-Strength] 



[T-lNACT] [T-PAR] 

[T-Repl] [T-Res] 

[T-lN],[T-OUT] 
[T-InC],[T-OutC] 



7,x: g?r.5h D x(y).P /i-(/ 2 ,x: h D x(y).P 

7,jc: (5,^),y: T h D /? (*) h^pv.T I 2 ,x: (S,S r ) h D R (**) 
I,x: (qlT.S,S')\-Dx(y).P h-(h,x: (q\T.S,S'))\- D x(y).P 

(*) q = un ^ q?T.S = S (**) q = un ^ qlT.S = S 

Figure 3: Split-based typing system 



The syntax of types and processes occurring in Figure [3] is that of Figure [T] Contexts I are a map from 
variables to types T: 

I ::= I Z,x: T . 



Typing rules in Figure [3] are based on a declarative definition of context splitting; the intuition is that 
unrestricted types are copied into both contexts, while linear types are placed in one of the two resulting 
contexts. We refer to [5 ] for the details. 

We introduce preliminary Lemmas and Definitions which will be useful to prove the main result of 
this section. Given a judgment Ti h Pi>r 2 of the algorithmic system of Section[3], we let the used closure 
of a type context T\ w.r.t. T 2 , noted Ti t>T 2 , be the typing context whenever Ti = 0, and be defined by 
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(Ti or2)(x) = Fi(x)>r2(x) otherwise: 

o>o = o lin/?i > Wnpi = o 

lin /?i >o = Wnpi un/?i > unpi = unpi 

(M,N)>{M',N') = (M>M',N>N') . 

The map operation projects a type environment T into a context / of Figure [3] When applied to a used 
closure, it permits to map linear typings which do not change from F\ to T2 into the unend type. 

map(o) = unend map(5)=S 
map((M,iV)) = (map(M),map(AO) map(r) = [J x:map(r(x)) 

.vedom(r) 

Lemma 4.1. Assume safe(Ti). IfFi h P>T 2 then map(ri >T2) is defined. 

A used closure generated by the algorithmic system is sufficient to type a process with the system ho, 
as we will show in a nontrivial manner below. We need a couple of lemmas for strengthening judgments 
of the algorithmic system and weaken judgments of the split-based system. 
Lemma 4.2 (Algorithmic strengthening). The following hold. 

1. IfF[,x : linp h P>F2, : X : Unp then T\ h P>r2; 

2. IfT u x : (Wnp,S) hP>r 2 ,x: (\\np,N) then T u x : 5 h P>F 2 ,x : N'; 

3. IfF u x: (M,\\np) hPt>r 2 ,x : (M',\\np) then F u x : M h P>T 2 ,x : M'; 

4. IfT u x: o\- P>T 2 ,: x: o thenT\ h P>F 2 ; 

5. Ifr u x:(o,N)hP>r 2 ,:x:(o,N') thenT u x : N h P>T 2 ,x : N' ; 

6. Ifr h x:(M,o)\-P>r 2 ,x:(M',o) thenTi,x:MY- P>T 2 ,x:M' ; 

7. IfTi,x : unp h Pt>r2,x : un a?i<ix fv(P) ?/ze« Ti h P>T2; 

8. IfT\,x : (unpi,unp 2 )\~ Pt>T2,x : (un/?i, un/?2) cindx fv(P) Ti h POT2. 
Lemma 4.3 (Weakening). 7,x : 5 ho P implies I,x : (S, un /?) ho P. 

We have all the ingredients to prove the following result which is the wedge of the proof of soundness. 
Lemma 4.4. Assume safe (ri). The following hold. 

1. IfY\ h v: r>T2 then map(ri >T 2 ) \~d v: T; 

2. IfTi\-P>T 2 thenm^{Ti>T 2 )\- D P. 

Proof. We first prove (1). Assume Ti,x: Ymp,T 2 \-x: \\npt>T\,x: o,T 2 . Notice that / = map((ri,r2) > 
(ri,r2)) is a safe type context such that un(/), i.e. it contains only unrestricted typings, and that lin/>>o = 
lin p. We apply [T-Var] and infer I,x : Unp ho x : lin p. The cases for typing a linear or unrestricted 
channel type, or an unrestricted channel type are analogous. Assume Ti,x: (\\np,N),T2 h x: Unpo 
Ti,x: (o,N),r 2 . Let / = map((ri,r2) > (ri,r2)). We have I(x) = (lin p,S) with S = unp' or S = unend. 
From these results and [T-VAR] we infer I,x : (lin p,S) h x : lin p. Now assume that T\~d x: unp>Y 
with r = Ti,x: (unp,N),T 2 . From un(map(rt>r)) and [T-VAR] we infer that there is S = unp' or 
S = unend such that un(map(ri>r)) hoi: (unp,S). We apply [T-STRENGTH] and infer the desired 
result: map(r>r) hox: unp. 

To prove (2) we proceed by induction on the length of the derivation for Ti h Pt>T2. We prove the 
most interesting cases. We use the notation r\x to indicate the context V whenever V = r',x : M or 
r = r',x: (M,N). 
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[A-Par] We have H h P \ Q>T 3 inferred from Ti h Pt>F 2 and Y 2 h Q>T 3 . We proceed by case 
analysis on T\. If T\ = we are done by applying the first rule for context splitting. Otherwise 
assume Ti = F,x : T. We exploit Lemma 4. 1 in order to infer the type of ^(x) and V 3 (x). 

(T = o). We have mapiTi >T2)(x) = unend and map(r2 >Tj)(x) = unend. We apply [T-PAR] 
to the I.H by using the second rule for context splitting to map(Ti >T2) ho P and map(r2 > 

r 3 )ho<2- " 

(T = (o,o)). Analogous to the previous case. 

(T = lin p). We have two cases for map(ri >T2)(jc) corresponding to (i) lin p and (ii) unend. In 
case (i) we have map(r2 ol^) = un p' . This is because by definition of map we have that 
Tz(x) = o. By applying Lemma 4.3 we weaken mapfTi t>T 2 ) and obtain an environment A 
equal to mapfTi o^) but for the entry x which is weakened to (lin p, un p'). We apply the I.H. 
and infer the desired result by applying the fifth rule for context splitting in [T-PAR]: A ho P 
and map(r2>r3) ho Q. In case (ii) we have ^(x) = lin/?. In sub case map(r2i>r3)(x) = lin p 
we apply the I.H. and proceed by weakening the type to (unend, lin p) in order to apply the 
sixth rule for splitting in [T-Par]. In sub-case m3^(T 2 \>T 3 ){x) = unend we apply the second 
splitting rule. 

(T = (lin pi,lin p 2 )). We have four cases for map(ri t>T 2 )(x) corresponding to (iii) (lin pi,lin p 2 ) 
and (iv) (lin /?i , unend) and (v) (unend, lin/?2) and (vi) (unend, unend). In case (iii) we infer 
r2(#) = (°)°)- We apply Lemma 4.2 and strengthen the algorithm's judgment by removing 
the entry for x in 1^2 : T 2 \x h Q>T 3 \x. We apply the I.H. and by [T-Par] we infer the 
desired result by applying the fourth rule for context splitting to map(ri >T 2 ) ho P and 
map(r2\xc>r3\x) \~d Q ■■ In case (iv) we have map(r2i>r3)(x) = (unend, S) where S = lin p 2 
or S = un,end. If 5 = \\np 2 we know that T 2 (x) = (o,linp2)- We apply Lemma 4.2 and 
infer both F,x : Unpi h P>F 2 \x,x : o and F 2 \x,x : lin/?2 l~ Q>^3\x '■ °- We apply the I.H. 
and infer the desired result by applying [T-PAR] with the fourth rule for context splitting: 
map(r,x : lin p\ >r2\x,x : o) \- D P and map(r2\x,x : \\r\p 2 \>T 3 \x,x : o) hp Q .. Otherwise 
when S = unend by strengthening and I.H. we have map(r,x : lin p\ >T2\x,x : o) ho P and 
map(r2\xi>r3\x) ho Q and we conclude by applying the third rule for context splitting. 

(T = (lin pi,o),= (o, lin p 2 )). Similar to the previous case. 

(T = unp, = (unpi,unp2),= (un/?i,o),= (o, un p 2 )). The result follows by applying the I.H. and 
the second rule for context splitting in [T-Par] to map(ri ol^) ho P and map^o]^) ho Q- 

[A-Out-L] We haven,*: lin \T.S hx(y).P>r 3 ,x : o inferred from Ti,x: o hv: Tt>T 2 andr 2 tt)x: 5h 
P>T 3 ,x : M provided un(M). By strengthening we infer Ti h v: Ti>r2\x. By I.H. we infer 
map(ri,x : 5i>r3,x : M) hoi 5 . Let A be the environment map(ri,x : Sol^x : M) but such that the 
type for x in A is equal to lin \T.(S>M). We apply [T-Out] and the fourth rule for context splitting 
and we conclude: map(ri >r2\x) - A. 

[A-Out-L-l] We have Ti ,x : (lin \T.S,N) h x(y) .P>F 3 ,x : (o, N) inferred from H ,x : lin IT.S h x{y) .P> 
Tj,x : o. By I.H. we infer map(ri,x: lin \T.S>r 3 ,x : o) ho x(y).P which we rewrite as map(ri > 
T3),x : lin \T.S ho x(y).P. Since N>N is unrestricted, by weakening we infer map(ri >r3),x : 
(lin \T.S,N>N) h D x{y).P. This is the requested result since map(ri >r 3 ),x : (lin \T.S,N>N) = 
map(ri,x: (lin \T.S,N)) >T 3 ,x : (o,N). 

[A- Repl] We have Ti h!P >r 2 inferred from Ti h P >T 2 provided Ti = r 2 . By I.H. we have map(ri > 
Ti) ho P- Since Ti >Ti is an unrestricted context, so is map(ri >Ti). We apply [T-Repl] and we 
conclude: map(ri >Ti) \~d\P. 
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[A-lNACT] We apply [T- In ACT] and infer map(r>r) h 0. 



□ 

By relying on this result we establish the soundness of the algorithm. 
Corollary 4.5 (Soundness). If typeCheck(7,P) then I h D P. 

Proof. If the algorithm succeeds then we have 7 h Pt>T with un(r). Consider x G dom(7). If I(x) = 
Wnp then we know that F(x) = o. Therefore map(7i>r)(x) = Wnp. Similarly, if 7(x) = (linpi, lin/?2) 
then map(/>r)(jc) = 7(x). The last possibility is 7(x) = unp,= (unpi,unp 2 ) and we conclude that 



map(7>r)(x) = I{x). From these facts we infer map(/>r) = 7. The result follows from Lemma 4.4 □ 



The hypothesis safe(7) in typeCheck(7,P) allows us to infer that typings are preserved by the system 
in Figure [3] in the following sense 10. 

Lemma 4.6 (Subject reduction). Assume safe(7). 7/7 ho P and P =>■ P' then I' ho P' with safe(7'). 

Finally we prove an important result, namely that the algorithm preserves structural congruence. To 



tackle the proof, we need a construction similar to the one of Lemma 4.4 
Lemma 4.7. Let T x h P>T 2 . We have T\ > F 2 h P > V r . with 



o r(x) = Wn,p 

(0,0) T(x) = (lin/?i,lin/? 2 ),= (lin 1 , c 

r(jc) x € dom(r) 



(o,lin/? 2 ) 



Given ri,r2 with the same domain we define the update of contexts ri,r 2 as the operation below: 

ri«r 2 



Mi l±)M 2 

(Mi tt) TVi , M2 W ZV2) 



riW 



:Mi,r 2 (x)=M 2 
: (Mi,M),r 2 (x) = (M 2 ,Af 2 ) 



Lemma 4.8 (Algorithmic weakening). Le? Ti h P>r 2 . The following hold. 

1. z/x0dom(r) then (i) F u x : M h Pt>r 2 ,x:M and (ii)r u x: (M,N) h P>r 2 ,x : (M,N); 

2. ifTt fcd T w de^nerf ^en H ttl T h P>r 2 l±l T. 

Lemma 4.9 (Sttuctural congruence). Asswrne P = Q. We have Ti h P>r 2 if and only ifF\ h 2>r 2 . 

Proof. The most interesting case is parallel composition. Assume Ti h P | 2 > T3 inferred from Ti h 



P>T 2 and T 2 h 2>r 3 . By Lemma|4.7|we have Ti t>T 2 h P>V r , and r 2 t>r 3 h Q> V r2 . In fact, it holds 
Vp, = V = Vr 2 . Let T4 be the solution of the linear system defined by equations Ti = (r 2 t>r3) and 
T4 = (ri >r 2 ) tt) Such a solution does exist (see the Appendix). By T 2 h Q>Tt, and Lemma |4?7] we 



infer T 2 i>r3l-2oV.By using Lemma 4. 8 we have r 2 T 3 1±) T 4 h g > V l±) T 4 . Next take Ti i> T 2 h P > V 



obtained by applying Lemma 4.7 to Ti h Pc>r 2 . We apply Lemma 4.8 and infer (Ti > T 2 ) t±J 1^3 I— P* > V tt) 
r 3 . Since the update of V with a type environment T, whenever defined, satisfies the equation V til T = T, 
the judgments above could be rewritten as Ti h 2>r4 and r 4 h Pc>r 3 . We apply [A-Par] and obtain 
ri \~ Q I Pt>r 3 , as required. The other direction for the parallel case is analogous. The second rule 
for congruence of parallel processes is straightforwardly obtained from the definition of [A-Par]. The 
cases for replication and inaction follow easily from the fact that the context received in output is equal 
to the context received in input. The cases for scope restriction follow from the definition of [A-Res] 



and from algorithmic strengthening and weakening (Lemmas 4.2 and 4.8). To illustrate, take the rule 
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(Vx : un p)0 = 0. Assume T h OoT and let x dom(r), eventually by alpha-renaming x in the left process. 
By weakening we infer F,x : unp h 0>r,x : un We apply [A-Res] and conclude: T h (vx : un /?)0[>r. 
Now assume rh (vx : un /?)0i>ri inferred from F,x : un/? h 0>ri,x : 0. From the fact that this judgment 
has been inferred by using [A-lNACT], we infer T\ = T and O = unp. Since x fv(0), by applying 
strengthening we infer the desired result, r h 1> T. □ 

Theorem 4.10. The typeCheck algorithm is effective for establishing a session-based type discipline. 
Proof. Apply Corollaries 3.4||4.5 and Lemmas 4.6 and 4.9 □ 



4.1 Towards semantic completeness 

The algorithm is unable to type check some process that is typable by the type system in Figure [3] This 
is trivially true for all processes typed by unsafe contexts, but also for typings of the form: 

T,x: (lin?r.5,lin!r.5)h D x(). J P P = C[x().P'} 

T,x : (lin?r.5,lin!r.5) h D x(x) T = WnlT.S . 

As argued in other works on session types (e.g. ||3] CD), it seems that ruling out such processes does 
not comport an issue since they appear to be deadlocked. To deploy a formal proof of this statement, we 
have developed a typed observational theory where the behavior of processes is contrasted w.r.t. the typed 
knowledge of the observer H . The discerning capability of the observer is regulated by the type checker; 
in particular, type checking forces contexts to not interfere with a session shared by two participants. 
Behaviorally equivalent pi calculus processes exhibit the same observables in all type checked contexts. 
To avoid universal quantification, we rely on a proof technique based on bisimulation over typed labelled 
semantics. 

The aim is to prove that if I ho P has been inferred by using [T-InC] or [T-OutC] with a lin- 
ear channel type, then P is indistinguishable from in all contexts type checked by a type environ- 
ment Y compatible with I, noted Y \= P = 0. To illustrate, assume that by applying [T-InC] we infer 
I,x: (lin?r.5, lin!T.5) \~d x(y).P. Intuitively, a process type checked by Y cannot tell apart the input pro- 
cess from because interaction on x is forbidden by Y; the compatibility condition enforces the type 
environment Y to do not contain input or output capabilities of x, which are already used in a linear way 
in /. Once obtained this result, we should be able to prove our algorithm to be semantically complete, in 
the following sense. 

Claim (Completeness). If I\ \~d P\ then there are a type environment h and a process P2 s.t. typeCheck(/2 , Pi) 
and Y \= P\= P2 with Y a type environment compatible with both I\ and I2. 

The idea is to build P2 by descending the derivation tree for I\ h Pi and by substituting subtrees of 
I\ h Pi with a leaf I2 h by following two rules: 

[T-InC] h,x: (lin?P.5, lin!P.5) h x(y).Q is exchanged with Z 2 h 0; 

[T-OutC] h,x: (linlP.S, lin?P.5) h x(v).Q is exchanged with 7 2 h 0; 

Ideally, we would let I\ = h_. Unfortunately, the linear design of the algorithm forbids this option 
since the call of the type checking function would return in output the linear entries not consumed by 
[A-lNACT]. This approach indeed works if we relax the linearity of type checking an relies on an affme 
setting where each session type is used at most once. Otherwise, we could prune the linear entries from 
h,x: (lin?P.5, linlP.S) and let the type environment 1% to contain all unrestricted typings in l\. The proof 
is performed by proceeding by induction while exploiting bisimulation semantics and contextuality of =. 
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As a by-product, this technique could be also useful to detect simple deadlocks generated by erro- 
neous programming of two opposite linear capabilities in a sequential way. 



5 Examples 

The protocol for the scheduling of a meeting discussed in Section [TJrequires the interaction with one or 
more clients executed in parallel with the service. The bootstrap is due to the interaction with a client 
process acting as the creator of the poll, defined as process P2 below. The process, once it has received 
the channel for the poll, sets the title and the date and then sends the invitation for the poll to a number 
of recipients by forwarding the channel established to communicate the date proposals. An instance of 
the protocol is obtained by considering the parallel composition of the service Pi and the client P2; we 
let string = un end = date. 

Pi =\x{w).{vp : (5i,5 2 )) (w(p).p(title).p(date).!/?(date)) 
Pi=x(y) .y(p).(p(Meeting).^(17March).(zT(p) | ■•• |^(p))) 

51 = lin?string.lin?date.S3 S3 = un?date.S3 

52 = lin Istring. lin !date.S4 S4 = un !date.S4 

By passing the (safe) context T below to the type checker we obtain that Pi | P2 is accepted. Notice that, 



due to Lemma 4.9 P2 | Pi is also accepted; we believe this feature to be of practical interest. For the sake 



of compactness, in the following we will shorten the unrestricted type unend with end. 

r = x : T x ,y : (lin !S2.end, lin ?S2.end),zi : lin !S4.end, . . . ,z.n '■ lin !S4.end 
T x = ( i Ua.un?(lin !S2.end).a , , i uft.un!(lin !S2.end).&) 

We present below the most interesting snippets of the execution of typeCheck( T, Pi | P% ). 

Typing the (linear) poll delegation. In typing the continuation of Pi, the [A-Res] pattern is matched. 
Once verified that the type (Si , S2) is balanced, the following sub-call is launched by adding to the context 
the channel type for the poll: 

T\ = check( F,w : lin !S2.end,p : (Si,S2) , w(/?)./7(title).p(date).!/?(date) ) (1) 

The call ([TJ matches the pattern [A-OiJT-L] and a call for the continuation is invoked by setting to void 
the sent end point type S2. 

T 2 = check( r,w : end,;? : (Si,o) , p(title)./;>(date).!/?(date)) (2) 

When receiving the context T2, the pattern [A-Out-L] requires ^(w) to be unrestricted. The context 
returned in output to the call in ([T]) is obtained by setting ^(w) = o. When receiving the context Ti, 
the pattern [A-Res] requires Ti (p) to be unrestricted, and the context returned in output to the caller is 
obtained by removing the entry for p from Ti . 

Typing the replicated receiving of the date. In typing the continuation of the process above the pattern 
[A-lN-L] is matched and the following call is launched by passing as parameter the context V = F,w : 
end,/? : S3, title : string, date : date : 
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T 3 = check(r' , !/>(date) ) (3) 
The pattern [A- Repl] is matched and the following call is launched. 

T 4 = check( r, p(date) ) (4) 



To succeed in returning the context in output, [A- Repl] requires the context r 4 received from the 
call Q to be equal to V. This is satisfied; in this way we know that any linear resource has not been 
used under replication, because that would have implied the presence of a new void typing. Finally the 
context 1^3 = r 4 is returned by [A- Repl] to the caller. 

Typing the (unrestricted) poll delegation. In typing the continuation of the client P%, pattern [A-Out-L] 
is matched and the following call is launched by passing as argument the context =x:T x ,y: (o, end),/? : 
£4,21 : lin !S4.end, . . . ,z n '■ lin !S4.end: 

r 5 = check(r 3 , zT(/>) \ ---\zT n {p)) (5) 

The call (|5]> matches the [A-Par] pattern and corresponds to the forwarding of the poll to the recipients 
in order to propose a date. The checking procedure for the first delegation is invoked: 

r 6 = check(r 3 , zl(/?)) (6) 

The context obtained by setting to void the entry for z\ in Hs is returned to the caller ([5]) in order to 
type the next thread. Lastly context ]"5 is obtained by setting to void the entries for zi, ■ • ■ ,z n in F^. 
Remark. By setting typings to void at the end of the call for a linear typing we avoid unsound derivations 
as the one below 

ri,x:\\n\T.unlT.S\ L x{v).P\x(y).Q>T 2 ,x:o . 

On contrast, we could type check a standard use of pi calculus channels by using the rules for unrestricted 
channel types of the form T = (/ta. un IT' .a,}ib.ur\ IT' .b): 

r h x:T\-x{y).P\x(y).Q>r z ,x:T . 

6 Discussion 

We have presented a type checking algorithm for establishing a session-based discipline in (a typed 
version of) the pi calculus of Milner, Parrow and Walker. Following a recent approach |[T4l our session 
types are qualified as linear or unrestricted; a linear session type could evolve to an unrestricted session 
type. Each session type describes one end of the session; the whole session is described by a type 
constructor representing the concurrent behavior of the two channel ends Q . We assess the soundness 
of the algorithm by showing that type checked processes are accepted by a typing system satisfying 
subject reduction. 

Similarly to other approaches for type checking of linear and session types in the pi calculus CJ|3l, 
we rely on the idea to type a parallel process P \ Q by ignoring the set of linear identifiers used by P before 
type checking Q. By reasoning at the type level, we provide for a clean account of the notion of used 
identifier by introducing explicit markers for consumed types. On contrast with the cited approaches, this 
construction let us prove that the algorithm preserves structural congruence, and in turn that re-arranging 
of parallel processes is possible; we think that this feature is of practical interest. 
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While the algorithm is not complete, we claim that we are not loosing expressiveness since the 
algorithm should type checks all interesting processes accepted by the split-based typing system. We 
are working on a proof of this result which is based on a typed observational theory which permits to 
contrast the behavior of processes w.r.t. contexts regulated by type checking H. 

Qualified session types are expressive enough to represent linear types for lambda calculus |[T5ll and 
linear and session types for pi calculus 0|3l: see @ for the details. The presented algorithm is therefore 
a useful tool to type check systems based on the notion of linearity of communications. For instance, the 
qualified session typing system presented in lfT3l for a variant of pi calculus relies on the idea of a double 
binder to represent the two ends of a communication. By projecting a qualified session type S into its 
dual 5 we could easily map this construct in our system and in turn provide a (different) type checking 
algorithm: 

l(vxy:S)P} = (vx:(S,SmP[ X /y]} 

It should be noted that the choice of representing computations with a channel type representing the 
two ends of the communication rules out some process that could be interesting. A process that we are 
not able to type check is below. 

!x(y).(va)(y(a).a(title).a(date).(!a(date) | a(22March)) 

The process consists in a modified version of the poll service where the service itself proposes a date 
for the meeting. Both the algorithm and the split-based system do not accept this process because in the 
(unrestricted) continuation type both capabilities would be needed. While we do not envisage difficulties 
in introducing subtyping for unrestricted types a la iTTTIl . this seems to go in the opposite direction of the 
idea of channel types. We therefore need to investigate subtyping solutions which take into account the 
channel type construct. 

Lastly, a natural completion of this work would be to deploy an algorithm for type inference. We 
are convinced that the channel type abstraction leads to a feasible implementation based on constraint 
techniques (e.g. Il8l). 
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A Appendix 

The table in Figure [4] depicts the shape of contexts used in the proof of the case of congruence of parallel 
processes in Lemma [4^9] The first three columns in the table represent all possible combinations for (an 
entry of) safe contexts T\ , r 2 and r 3 such that 

F 1 hP>F 2 and T 2 h Q>T 3 

Given these inputs, the next three columns show the output for the context in the header. Context T4 in 
the seventh column is the solution of the following linear system: 

ri = (r 2 >r 3 )wr 4 
r 4 = (ri>r 2 )wr 3 

In the last column we have the environment Vr-j = V = Vp 2 . 



114 



A type checking algorithm for qualified session types 



n 


r 2 


r 3 


ri>r 2 


r 2 >r 3 


ri>r 3 


r 4 


V 


lin p 


lin p 


lin p 











lin /? 





lin p 


lin /? 








lin p 


lin p 








lin p 


o 





lin p 








lin p 





un p 


un p 


un /? 


un p 


un p 


un /? 


un /? 


un p 


o 


o 




















(linpi,lin/> 2 ) 


(linpi,lin^ 2 ) 


(lin/>i,linp 2 ) 


(°,°) 


(°,°) 


(°,°) 


(linpi,lin/> 2 ) 


(0,0) 


(lin/?i,lin/? 2 ) 


(linpi,linp 2 ) 


(linpi,o) 


(°,°) 


(o,linp 2 ) 


(o,\\np 2 ) 


(lin/71,0) 


(0,0) 


(lin/5i,lin/? 2 ) 


(linpi.o) 


(lin/?i,o) 


(o,lin/? 2 ) 


(°,°) 


(o,\\np 2 ) 


(lin/?i,lin/? 2 ) 


(0,0) 


(linpi,lin/? 2 ) 


(lin/?i,lin/? 2 ) 


(o,lin/? 2 ) 


(°,°) 


(linpi,o) 


(lin/?i,o) 


(o,lin/? 2 ) 


(0,0) 


(linpi,lin^ 2 ) 


(o,linp 2 ) 


(o,lin/? 2 ) 


(linpi,o) 


(°,°) 


(linpi,o) 


(lin/)i,linp 2 ) 


(0,0) 


(linpi,linp 2 ) 


(lin/?i,lin/? 2 ) 


(0.0) 


(°,°) 


(linpi,linp 2 ) 


(linpi,linp 2 ) 


(0,0) 


(0,0) 


(linpi,lin/? 2 ) 


(lin/?i,o) 


(°>°) 


(o,lin/? 2 ) 


(linpi,o) 


(lin/?i,lin/? 2 ) 


(o,linp 2 ) 


(0,0) 


(linpi,lin^ 2 ) 


(o,linp 2 ) 


(°>°) 


(linp!,o) 


(o,linp 2 ) 


(linpi,linp 2 ) 


(linpi.o) 


(0,0) 


(linpi,lin^ 2 ) 


(°,°) 


(°>°) 


(lin/7i , lin/3 2 ) 


(°,°) 


(linpi,linp 2 ) 


(linpi,lin/> 2 ) 


(°)°) 


(linpi , o) 


(lin^i,o) 


(lin/?i,o) 


(°,°) 


(°,°) 


(°,°) 


(lin/>i,o) 


(0,0) 


(lin/?i,o) 


(linpi.o) 


(o,°) 




(linpi,o) 


{\\np h o) 


(0,0) 


(0,0) 


(linpi , o) 


(0,0) 


(°>°) 


(linpi,o) 




(linpi,o) 


(lin/?i,o) 


(°>°) 


(o,linpi) 


(o,linpi) 


(0, linpi) 


(°,°) 




(0,0) 


(0, linpi) 


( >°) 


(o,linpi) 


(o,lin/?i) 


(°>°) 




(0, lin/?!) 


(0, linpi) 


(°,°) 


(°>°) 


(o,linpi) 


(°,°) 


(°>°) 


(o,linpi) 




(0, linpi) 


(0, linpi) 


(°)°) 


(un/5i,un/? 2 ) 


(un/?i,un/? 2 ) 


(unp u unp 2 ) 


(un/?i,un/? 2 ) 


(un/5i,un/? 2 ) 


(unp u unp 2 ) 


(unp u unp 2 ) 


(unp u unp 2 ) 


(un/?i,o) 


(un/?i,o) 


(un/?i,o) 


(un/? 1; o) 


(un/?i,o) 


(unpi,o) 


(un/?i,o) 


(unp u o) 


(o,un/? 2 ) 


(o,un/? 2 ) 


(o,unp 2 ) 


(o,un/? 2 ) 


(o,un/> 2 ) 


(o,unp 2 ) 


(o,un/? 2 ) 


(o,unp 2 ) 


(°,°) 


(°,°) 


(°>°) 


(0,°) 


(0,0) 


(0,°) 


(0,0) 


(0,0) 



Figure 4: Contexts in [A-Par] 



